home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000168_owner-urn-ietf _Thu Nov 14 22:09:26 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id WAA29418 for urn-ietf-out; Thu, 14 Nov 1996 22:09:26 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id WAA29413 for <urn-ietf@services.bunyip.com>; Thu, 14 Nov 1996 22:09:24 -0500
  3. Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA24895  (mail destined for urn-ietf@services.bunyip.com); Thu, 14 Nov 96 22:09:07 -0500
  5. Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
  6.           id WAA19223; Thu, 14 Nov 1996 22:06:36 -0500 (EST)
  7. Message-Id: <199611150306.WAA19223@ig.cs.utk.edu>
  8. X-Mailer: exmh version 1.6.7 5/3/96
  9. X-Uri: http://www.cs.utk.edu/~moore/
  10. From: Keith Moore <moore@cs.utk.edu>
  11. To: dgd@cs.bu.edu (David G. Durand)
  12. Cc: urn-ietf@bunyip.com, moore@cs.utk.edu
  13. Subject: [URN] Re: I18N does not belong in URNs 
  14. In-Reply-To: Your message of "Thu, 14 Nov 1996 12:13:21 EST."
  15.              <v02130500aeb0fc2678c3@[128.148.157.46]> 
  16. Mime-Version: 1.0
  17. Content-Type: text/plain; charset=us-ascii
  18. Date: Thu, 14 Nov 1996 22:06:36 -0500
  19. Sender: owner-urn-ietf@services.bunyip.com
  20. Precedence: bulk
  21. Reply-To: Keith Moore <moore@cs.utk.edu>
  22. Errors-To: owner-urn-ietf@bunyip.com
  23.  
  24. > This means the human meaningfulness is not a requirement of URNs. This is
  25. > probably good. But it is _not_ as you have claimed, a requirement that URNs
  26. > _not_ be human-readable.
  27.  
  28. I agree, the charter does not prevent the existence of human-readable URNs.
  29.  
  30. >     As I have repeatedly pointed out, compatibility with existing
  31. > persistent namespaces will require that at least some human-meaningful
  32. > names be included. The notion of requiring users of FPIs (for instance) to
  33. > hex-encode 50+ character ascii strings stil strikes me a ludicrous. But
  34. > once we allow ASCII, we have to meet the questions of the international
  35. > community. My feeling is that transcribability is a more serious problem
  36. > than the UTF-8 advocates are admitting. On the other hand, if the reference
  37. > string is the %-encoded UTF-8 value, then we should be OK for
  38. > transcribability. The issue of user-friendly software that hides %-encoding
  39. > is not part of the protocol, so its _possibility_ shouldn't unduly
  40. > influence us.
  41. > 
  42. >    We can define the standard as %-encoded UTF-8, and if people implement
  43. > this other ways, they are implementing convenience features in the
  44. > interface: the software will always have the %-encoded URN available. This
  45. > might hurt me in typing in Japanese URNs from a Japanese-language paper
  46. > publication, but the scenarios where non-Japanese speakers will be doing
  47. > such tasks are pretty contrived.
  48.  
  49. This all sounds reasonable to me.  Maybe we've arrived at the best
  50. possible compromise.
  51.  
  52. -Keith
  53.  
  54.